ble: port the 5/MG CLIENT_HELLO suppression to iOS/macOS (#1635) - #1672

…OS) (#1673)

The gap #1672 left open. iOS issued the DIS identity read only inside the
post-bond handshake, so a 5/MG that never bonds never read DIS at all - and
since the #1635 suppression landed, "never bonded" is a PERMANENT state on these
straps rather than a transient one. The Devices screen showed a WHOOP 4.0 with
its firmware beside a 5/MG with none, and MG-only capabilities stayed locked
because the strap never got to attest what it is. Android has had this since
#1647/#1649/#1653.

Ported: shouldReadDisUnbonded, disRefusedPrefKey, disReadFailureLine and
shouldPublishDisFirmware as a pure Strand/BLE/DisUnbondedRead.swift twinning
DisUnbondedRead.kt; the unbonded attempt itself, scheduled from the suppressed
path and nowhere else, because that is the only 5/MG state known to be stable;
and the four DIS characteristics this platform never read - firmware (0x2A26),
manufacturer, model number, software revision.

Firmware is the point of it. DIS 0x2A26 is the ONLY source an unbonded strap
has, since the puffin report needs the bond that never happens - and #1634
records that the 5/MG hello frequently decodes no firmware even when it DOES
bond, so this fills a real void rather than racing a value that is coming.
Published as a FALLBACK, never an override.

Self-limiting, deliberately. A read is the same class of operation as the write
that provokes the teardown, so this could cost the stable link the suppression
just bought: once per link, and never again on a strap that has refused once. A
refusal is a RESULT - it settles #490, which no capture has ever done - so it is
reported with its status rather than swallowed by the generic notify-failure
line.

Five review passes found five defects, and the last two are the ones worth
reading:

  - the ECG PROBE was blocked only by accident. Its gate checks opt-in, attested
    MG and connected - but not the bond. On a suppressed strap the MG check
    blocked it incidentally, because the variant could only resolve from a
    post-bond read. Reading DIS unbonded removes that accident, and the gate
    would then have let the probe write puffin frames to fd4b0002 - the very
    characteristic whose write tears the link down, spending the stable link the
    suppression exists to buy. send() is no backstop: it guards connected, not
    bonded. The gate now requires the encrypted bond, as the ECG GATE-WRITE path
    always did (#269).
  - the per-device firmware key had readers and NO writer. I first claimed iOS
    had no FirmwareAttribution twin; that was wrong, and wrong because I grepped
    Kotlin's names against Swift. It exists, has tests, and is read by
    DevicesView and the debug export - but the decoded path cannot key on
    identity, which its own comment concedes, so perDevice always resolved nil
    and both readers fell back to a global value that is wrong the moment a
    second strap exists. The DIS site has the peripheral, so it is the one place
    that can attribute a firmware honestly. That fills a hole predating this
    change.

Also from the passes: the delayed read now checks `connected`, because
`peripheral` outlives a disconnect on this platform and the line would otherwise
claim an attempt that never happened; three comments still describing the read
as post-bond-only were corrected; and the delay is pinned to the twin's actual
number (1500 x 2 = 3.0s, not the 4.0 I first guessed).

Deliberate divergences, all documented in code: the extras are issued together
rather than chained, because CoreBluetooth already serialises reads; the refusal
latches only for an UNBONDED attempt, since a transient failure on a bonded link
would poison a permanent latch; there is no explicit-bond-deferred call site,
that experiment being Android-only; and the post-bond path stays silent about a
missing serial, because it is re-entered from the keep-alive tick and would log
every cycle.

Verification: disReadFailureLine and both firmware log lines proven
byte-identical to the Kotlin source by extracting and comparing - which caught a
hyphen where Kotlin has an em-dash. All six DIS UUIDs verified against the twin.
14 tests over the pure rules incl. every arm of the attempt gate, the
fallback-not-override rule, and that the DIS latch key cannot collide with the
hello-suppression one; the pure file also compiled standalone with swiftc and
every rule exercised. doc_comment_lint and the i18n gate clean.

NOT hardware-validated, and this one is genuinely unproven rather than merely
untested: whether a 5/MG answers a standard read on an unencrypted link is the
open question #490 asks, and nothing here can settle it without a strap. Either
outcome is informative, and a refusal costs one read per strap, once.